As computers become more commonplace in everyday life, so do the demands on the functionality they provide. As such, computer programs are increasingly growing in size resulting in program bloat, data corruption, and “spaghetti” code. A very popular solution to these problems is provided through applets. An applet is generally a small part of an application that can be distributed economically. For example, an applet may display a document on a computer screen, spell-check a document, or play a sound file. Programs written in the Java language are often organized into applets. Applets can be interpreted at run-time, in part, because of their relatively small size.
When developing applets (in Java for example) which requires special permissions such as reading or writing from the client's hard drive, it is necessary to make special requests to a browser's proprietary security application programming interface (API). Different types and brands of browsers often require different requests and use different names for the types of permissions included with the requests.
In addition to different interfaces, browsers generally require that the request for the privilege and the actual use of that privilege be made on the current call stack. For example, a Java method which reads from a client's hard drive needs also be the method which makes the request for the permission from the browser. In many instances, the Java classes that run as part of an applet in a browser may also need to run in other environments (e.g., stand-alone and as part of a Java servlet on a web server). Since the browser APIs may not exist in these environments, classes which use them may not compile correctly. Furthermore, there may be no need to use these APIs in any case. Accordingly, the present solutions pose a number of shortcomings, which hinder the efficient growth and/or utilization of implementations utilizing applet-type solutions.